Summary
Placeholder for Alex Russell’s “Five True Things” browser discussion. Treat this as a senior interview note about respecting the browser as a constrained, distributed runtime.
Interview Points
- Browser performance is shaped by network, CPU, memory, battery, and user device constraints.
- The frontend is not just UI; it is part of a distributed system.
- Good browser engineering means reducing work, scheduling work carefully, and measuring real user impact.
- Progressive enhancement and resilience matter because users arrive with different devices, browsers, and network quality.
2-3 Minute Interview Script
“The way I think about browser engineering is that the browser is a constrained runtime running on someone else’s device. We do not control CPU, memory, battery, network, extensions, or the exact browser version.
For senior frontend design, that means I optimize for less work first: fewer bytes, less JavaScript, fewer layout recalculations, and fewer main-thread stalls. I also design for progressive delivery, so the core experience works even if non-critical features load later.
In an interview, I would connect this to system design by saying the frontend is part of the distributed system. Latency, caching, retries, auth, observability, and graceful degradation all show up in the browser too.
My default approach is to measure with real user metrics, protect the main thread, keep critical rendering paths small, and make failure states intentional rather than accidental.”
Follow-Ups
- How would you debug a slow page on low-end devices?
- What would you move from client to server?